The invention concerns a method, a device system and a computer program product for processing of a document data stream that contains structured fields. A typical document data format of this type is the format AFP™ (advanced function presentation). It is in particular used in electronic print production environments, i.e. in data processing and printing systems that process document data with a speed of up to a few thousand pages per minute.
Such document production systems exhibit a high degree of automation. For example, a printing system with integrated quality checking is specified in U.S. Pat. No. 6,137,967.
Various print data streams and printing systems are, for example, specified in the publication “Das Druckerbuch”, Dr. Gerd Goldmann (editor), Océ Printing Systems GmbH, 6th edition (May 2001), ISBN 3-000-00 1019-X. The server system Océ PRISMApro is specified in chapter 14. This flexible print data server system is, for example, suited to transfer print data from data sources such as a source computer—the print data in a specific print data language such as line data, AFP, PCL (Printer Command Language), PostScript, SPDS (Siemens Print Data Stream), or in the language LCDS developed by the company Xerox Corporation—to a print production system.
Details of the resource-structured document data stream AFP™ are specified in the publication Nr. S-544-3884-02, published by the company International Business Machines Corp. (IBM) with the title “AFP Programming Guide and Line Data Reference”. This documentation is to be obtained via the address IBM Printing Systems Division, Dept. H7FE, Building 004M, Information Development, PO Box 1900, Boulder Colo. 80301-9191 USA or via \http://publib.boulder.ibm.com/prsys/pdfs/54438842. pdf.
The document data stream AFP was further developed into the resource-structured document data stream MO:DCA™, which is specified in the IBM publication SC31-6802-05 (April 2001) with the title “Mixed Object Document Content Architecture Reference”. This document is also accessible at the Internet address http://publib.boulder.ibm.com/prsys/pdfs/c3168025.pdf. Details of this data stream, in particular the use of structured fields, are also specified in U.S. Pat. No. 5,768,488. In the framework of the present specification, no differentiation is made between AFP and MO:DCA data streams.
AFP/MO:DCA data streams are frequently converted into data streams of the format Intelligent Printer Data Stream™ (IPDS™) in the course of print production jobs and transferred to a high-capacity printer in this format. Such a process is shown in U.S. Pat. No. 5,982,997.
In the specification “UP3I; Universal Printer Pre- and PostProcessing Interface,” Version 1.02 (July 2002), published by the companies Duplo International Ltd., Hunkeler AG, IBM Corporation, Océ Printing Systems GmbH and Stralfors AB, which can be downloaded as a file at the Internet address www.up3i.org, the most varied control commands are provided that can be used in the creation of a printed document to control various devices of a print production system such as printing devices and devices upstream and downstream from these, such as unwinders, cutting devices, hole devices, gluing devices and binding devices. It is thereby provided that such data are exchanged between the different devices, thus for example between a paper dispenser and a printing device.
On the pages 134 through 141 of the UP3I specification, examples are already cited as to how commands for print pre- and post-processing devices can be inserted into an AFP (MO:DCA) or IPDS data stream. With the UP3I extensions, AFP applications can now contain UP3I control commands that are transferred to a printer, whereby printer-specific data formats such as IPDS can be used. The UP3I control data are thereby initially mixed with the print data and are only separated from these in the printer. The further devices of the print production system, i.e. pre- and post-processing devices for the print good (such as paper dispensers, unwinders, stackers, punchers, folders, cutters and binders), can then be addressed via the UP3I interface.
New AFP applications can already be coded from the beginning such that UP3I functions are used. This is different than in older AFP applications. Such applications for standard expressions (such as, for example accounting printouts or account statements), applied in part for many years, must be changed when they should use UP3I functions.
From the IBM publication NR. S544-5284-06, “IBM Page Printer Formatting Aid: User's Guide”, 7th edition, which is accessible at http://publib.boulder.ibm.com/prsys/pdfs/54452846.pdf, a tool is known with which a user can provide an existing AFP document data stream or a format definition resource file “Formdef” located in this document data stream with additional commands. This occurs via a control file in which it is entered when what is known as a copygroup or medium map with a specific name must be generated.
In this type of data enhancement, corresponding calls of the media map must respectively be stored in the file in which the variable data are situated in order to be able to let the commands generated in the formdef file act on the variable data. This manual reprogramming of the data stream can be a very complex event that is error-prone—primarily when a plurality (for example 3 or more) of copygroups are to be newly inserted. The effort thereby resulting for the user is substantial, and the danger of wrong inputs exists when media map calls are not correctly updated, for example not changed in synchronization with the entries in the formdef file.
Furthermore, it can occur that one and the same original data stream are processed with various print production systems, and this with various finishing possibilities. The application must then be re-adapted for the respective configuration of the print production system, which can lead to unwanted time delays under production conditions.
In the patent application Nr. PCT/EP02/05299, which the applicant submitted on 14 May 2002 with the title “Method, device system and computer program system for processing of document data”, it is described how auxiliary data (such as, for example, barcodes) can be automatically inserted into a document data stream.
A conventional processing of an AFP print document data stream without support of finishing or UP3I functionalities is shown in FIG. 2. The various processing steps show what an AFP application designer (user) has to do in order to create an application: by means of a formatting computer program 20 (which, for example, can be the previously mentioned Page Printer Formatting Aid (PPFA) tool by the company IBM or the Smart Layout Editor (SLE) specified in the Druckerbuch introduced above) and a control file 21 with corresponding formatting parameters, the user generates a formdef file (resource) 23 that contains a copygroup (medium map) with the name ACCOUNT.
A print data file 22 that contains variable data is prepared by the user such that it is called the copygroup which has been applied with the control file 21 with structured fields of the type invoice medium map (IMM) “IMM Account”, which stands between the variable data. Details regarding the structured field type IMM can be learned from the previously cited IBM document SC31-6802-05.
In the example shown in FIG. 2, the print data file contains account statement documents for two different customers of a bank. For the first customer, the print data file 22 contains two account statements with respectively 9 pages and 6 pages. For the second customer, an account statement document with 3 pages should be printed out. For this, the print data file 22 and the formdef file 23 are supplied to a host printer driver 24 that (in step S3) forms a print data stream of the format IPDS from both files and, if applicable, resource files such as, for example, fonts, with which a print data stream an IPDS-capable printing system 25 is activated. In the illustrated example, the printing system 25 is controlled from a first printer 26 in which the front side of a web-form recording medium is printed and a second printer 27 in which the back side of the same recording medium is printed with the respectively associated data.
In step S4, the previously cited documents are printed out, i.e. as a first document 28 of the first printout of the first customer that comprises five individual pages, three pages as a second document 29 for the first customer with the second account statement, and two pages as a third document 30 for the second customer.
The same application as shown in FIG. 1 is shown in FIG. 3, whereby it is manually extended with additional commands for print pre- or post-processing devices as they are provided in the UP3I specification. In the case of FIG. 3, the finishing commands shrink-wrapping (shrink-wrap), page offset (left/right/shift) as well as document stapling (corner staple) are provided that should be applied on the printed print good or parts thereof. Using FIG. 3, it is described which operating steps are necessary when this goal is executed with the already specified tool by the company IBM, “Page Printer Formatting Aid” (PPFA) or with the Smart Layout Editor (SLE) known from the applicant.
In step S5, a new form definition file is generated by the user as a resource file with the Page Printer Formatting Aid tool (see above) or with the tool Small Layout Editor (SLE) that is specified in the previously introduced “Druckerbuch” by Océ Printing Systems GmbH. The parameters are specified in a PPFA control file 31 (in FIG. 3, the control file 31 is subdivided into a first part 31a and a second part 31b merely for representation reasons). The control file 31 shows that three copygroups (medium map fields) are necessary in order to be able to activate the desired finishing functions. The UP3I control commands for the welding, the offset, and the stacking are part of the new medium map, for example OPERATION SHIFT and REFERENCE left for the offset.
The PPFS control file 31 generated in the step S5 uses the PPFA computer program 32 in order to generate in the step S6 a formdef file in which are contained the copygroups (LI_ACC1, LI_ACC2 and RI_ACC1) defined in the PPFA control file 31. These new medium maps replace the copygroup (medium map) ACCOUNT contained in the formdef file 23 in FIG. 1.
In addition to the changes in the formdef file 23, the user must modify the print data file such that the structured fields Invoice Medium Map (IMM) are synchronized with the new medium map names. The user must thereby replace the respective old IMM call with a correct new IMM call that corresponds to the respective desired finishing operations. In the example of FIGS. 2 and 3, different calls are henceforth inserted in place of the respective identical calls 22a, 22b and 22c “ACCOUNT” for the three documents 28, 29, 30: the call IMM LI_ACC1 34a, whereby the document is distributed and stapled to the left, is to be added to the document 28 and the call IMM LI_ACC2 34b, whereby the document is deposited and stapled to the left, is to be added to the document 29. The call RI_ACC1 is to be added for the document 30, whereby the document is deposited and stapled to the right. This association must occur manually in the print data file when the print data file exists already or has the structure 22 shown in FIG. 1. Otherwise, the print data file would have to be completely newly generated via a corresponding application program, which is, however, very time-consuming under the circumstances. For synchronization, it is thus necessary that copygroups a) are present, b) have matching parameters for formdef file in the data stream and c) their calls are situated at precisely the right point of the print data stream.
In step S8, the formdef file 3 and the print data file 34 are in turn converted by the host printer driver 24 from the AFP format into an IPDS print data stream and sent to the IPDS-capable printing system 25. The commands, which apply to the pre- or post-processing devices (UP3I commands) and that are contained in the medium map, are converted into corresponding IPDS/UP3I triplets before they are sent to the printer. As already in FIG. 2, the resulting printed documents 28, 29, 30 are grouped, whereby in the case of FIG. 3 the pages are stapled and shifted group-by-group, and all are shrink-wrapped together in a protective covering as this has been specified by the user.
The labeled bars 35, 36 show the respective post-processing steps of the ancillary documents.
A user that would like to extend an AFP print data stream with post-processing functionalities (for example UP3I) with the method shown in FIG. 3 must have the original PPFS control file available and furthermore have access to the user program that has generated the original print data stream. However, this is not always given. It is therefore a requirement to expand existing AFP print data streams with additional device functionalities in order to enable an optimally automated process for generation of more complex documents without having to access old control files or user programs that were decisive in the generation of the data stream.
To recapitulate, it is to be established that the user must implement at least the following steps in the method shown according to FIG. 3:                a) He must change existing copygroups which contain a finishing operation. Tools such as the computer program PPFA are available for this.        b) He must add new copygroups that are respectively situated at the beginning of a finishing operation or indicate their continuation and        c) he must modify the print data stream in order to call the modified or inserted medium maps (copygroups).        
The steps cited above are all the more elaborate the larger the respective application, i.e. the more documents that are contained in the application and/or the more medium maps/copygroups that are contained in the formdef file. Typical AFP applications are comprised of multiple thousands (up to hundreds of thousands) of pages. A typical AFP formdef file contains a plurality of medium maps, for example in what is known as a mixplex job, in which various paper feeder bays and/or simplex/duplex print commands alternate within a print job. Effort and susceptibility to error are therefore very high under the circumstances given the preparation of such print data streams.
Possibilities for insertion of information into a MO:DCA data stream are specified in U.S. Pat. No. 5,768,488. Furthermore, in the article PrePress, published 8/99, pg. 18-27, it is specified that the host input module of the program “Hausdruckerei Manager”, vers. 6.1 by the system vendor Danka allows the addition of information that are not contained in AFP/IPDS data streams, for example commands for duplex printing and end processing.
A method for enhancement of a document data stream with data for peripheral devices is known from DE 100 24 523 A1.
From the document EP-A-1 139 275, it is known to search through a GDI print data stream for address data that are extracted from this print data stream. The extracted data are subsequently re-supplied to the data stream.
From the document EP-A-1 156 411, it is known to create an electronic job ticket with whose help a print data stream is generated from unprintable data that comprises the templates and text data.
From the document WO 01/77807 A2, a method and system for processing of a print data stream are known that converts a print data stream of a first data format into a print data stream of a second standardized format.
The previously cited publications and patent applications are herewith incorporated by reference into the present specification.